The 3rd Generation Partnership Project (3GPP), as a standardization organization drafting 3rd communication technology standards, has provided on the core network an ability to broadcast and multicast multimedia since R6 version. The specific implementation is that, a new network element, i.e. a Broadcast Multicast Service Centre (BM-SC) is added to the core network to serve as a data source of MBMS in UMTS networks. The BM-SC is used to manage MBMS, for example, to provide a membership function, a session and transmission function, a proxy and transport function, a service announcement function, a security function, etc. The BM-SC is connected with a GPRS Gateway Service Node (GGSN) directly so as to send the MBMS data to the UMTS networks.
After the R6 version, 3GPP evolved network may also provide the ability of broadcast and multicast through such processes as MBMS registration, MBMS session start, MBMS data transfer, MBMS session stop, MBMS de-registration, etc. Additionally, the 3GPP evolved network may support multicast services from Internet as well, so that the multicast services from Internet are allowed to transmit on the 3GPP evolved network.
In the 3GPP evolved network, the MBMS may implement an entire MBMS multicast services through such processes as subscription, service announcement, joining, session start, MBMS notification, data transfer, session stop, leaving, etc. A node in charge of transmitting data and signaling needs to use two parameters: MBMS UE Context and MBMS Bearer Context, wherein the MBMS UE Context is associated with a UE, and the MBMS Bearer Context is associated with a bearer.
When a first UE registers on a node, the node establishes an MBMS Bearer Context and registers to its upstream node. In each MBMS Bearer Context, there is set a list of downstream nodes. On receiving a registration request from its downstream node, the node adds the downstream node to the list of downstream nodes. If there are some data and signaling to be transmitted in a downstream direction, the node uses its list of downstream nodes to establish a bearer with its downstream nodes, and issues the contents such as data, signaling, etc. to its downstream nodes through the bearer.
According to the existing multicast technology, each multicast service defines a multicast area. Subscribers can receive the multicast service only in the multicast area. The multicast area includes a plurality of local multicast areas. Data played in different local multicast areas by multicast services of a same type may be different, which is implemented through different multicast bearers. For example, multicast services of the same type can be transmitted through multiple multicast bearers, and different local multicast areas use different multicast bearers to distribute data of the multicast services of the same type.
Thus, if the local multicast area where the subscriber is located is changed, the data corresponding to the multicast services of the type are expected to be changed correspondingly. Taking the multicast service such as a “weather forecast” as an example, if a subscriber subscribes the “weather forecast” in Beijing, and then roams to Shanghai, the subscriber will want to receive the weather forecast of Shanghai; in other words, the subscriber wants to receive the weather forecast of Beijing in Beijing, and receive the weather forecast of Shanghai in Shanghai.
However, the actual situation is that, after registering at an original local multicast area, if the subscriber leaves the original local multicast area and enters a new local multicast area, the multicast service needed by the subscriber is interrupted, since the multicast bearers used in the two local multicast areas can not establish connections with each other due to the use of different service identifiers (IDs). If the subscriber wishes to continue the multicast service in the new local multicast area, the subscriber has to receive a service announcement through the multicast bearer in the new local multicast area, and access the multicast service of the type again. The service announcement includes parameters such as a service ID, a multicast address (referring to the address of the multicast source providing the multicast service), and so on. The above-mentioned process relates to some subscriber's operations such as re-registration and the like, which makes the subscriber inconvenient, and is possible to be an obstacle of receiving multicast services.
Even if the subscriber leaves the original local multicast area and enters the new local multicast area after receiving the service announcement in the original local multicast area and acquiring access parameters (for example, the multicast address, etc.), the subscriber can not acquire the multicast service at the new local multicast area using the multicast address acquired before.